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Foreword 



The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes all procedures that assign, reconfigure and release radio resources. Included are 
e.g. procedures for transitions between different states and substates, handovers and measurement reports. The emphasis 
is on showing the combined usage of both peer-to-peer messages and interlayer primitives to illustrate the functional 
split between the layers, as well as the combination of elementary procedures for selected examples. The peer-to-peer 
elementary procedure descriptions are described in the related protocol descriptions /I, 2, 3/ and they are thus not within 
the scope of the present document. 

The interlayer procedures in the present document are informative. 

Following items are considered for releases beyond release 99: 

asymmetric Transport Channel Reconfiguration; 

support of downlink shared channel in FDD-mode using one TFCI-word on the physical layer when SRNC <> 
CRNC. 
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• References are either specific (identified by date of publication, edition number, version number, etc.) or 
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• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] 3GPP TS 25.321: "MAC Protocol Specification". 

[2] 3GPP TS 25.322: "RLC Protocol Specification". 

[3] 3GPP TS 25.331: "RRC Protocol Specification". 

[4] 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 

Mode". 

[5] 3GPP TS 25.301: "Radio Interface Protocol Architecture".* 

[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2" 

[7] 3GPP TS 25.323: "PDCP Protocol Specification". 



Void 



4 General Description of Connected IVIode 

The connected mode is entered when the RRC connection is established. The UE is assigned a radio network temporary 
identity (RNTI) to be used as UE identity on common transport channels. Two types of RNTI exist. The Serving RNC 
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allocates an s-RNTI for all UEs having an RRC connection. The combination of s-RNTI and an RNC-ID is unique 
within a PLMN. c-RNTI is allocated by each Controlling RNC through which UE is able to communicate on DCCH. 
c-RNTI is always allocated by UTRAN when a new UE context is created to an RNC, but the UE needs its c-RNTI only 
for communicating on common transport channels. 

The UE leaves the connected mode and returns to idle mode when the RRC connection is released or at RRC 
connection failure. 

Within connected mode the level of UE connection to UTRAN is determined by the quality of service requirements of 
the active radio bearers and the characteristics of the traffic on those bearers. 

The UE-UTRAN interface is designed to support a large number of UEs using packet data services by providing 
flexible means to utilize statistical multiplexing. Due to limitations, such as air interface capacity, UE power 
consumption and network h/w availability, the dedicated resources cannot be allocated to all of the packet service users 
at all times. 

Variable rate transmission provides the means that for services of variable rate the data rate is adapted according to the 
maximum allowable output power. 

The UE state in the connected mode defines the level of activity associated to the UE. The key parameters of each state 
are the required activity and resources within the state and the required signalling prior to the data transmission. The 
state of the UE shall at least be dependent on the application requirement and the period of inactivity. 

Common Packet Channel (CPCH) uplink resources are available to UE's with an access protocol similar to the RACH. 
The CPCH resources support uplink packet communication for numerous UEs with a set of shared, contention-based 
CPCH channels allocated to the cell. 

Packet Services can be supported also using the FAUSCH, by means of which a dedicated transport channel can be 
allocated for data transmission. 

The different levels of UE connection to UTRAN are listed below: 

No signalling connection exists 

The UE is in idle mode and has no relation to UTRAN, only to CN. For data transfer, a signalling connection has 

to be established. 

Signalling connection exists 

When at least one signalling connection exists, the UE is in connected mode and there is normally an RRC 

connection between UE and UTRAN. The UE position can be known on different levels: 

- UTRAN Registration Area (URA) level 

The UE position is known on URA level. The URA is a set of cells 

- Cell level 

The UE position is known on cell level. Different transport channel types can be used for data transfer: 

- Common transport channels (RACH / EACH, DSCH, CPCH) 

Dedicated transport channels (DCH) (FAUSCH can be used to allocate a dedicated transport channel for data 
transmission.) 

Assuming that there exists an RRC connection, there are two basic families of RRC connection mobility procedures, 
URA updating and handover. Different families of RRC connection mobility procedures are used in different levels of 
UE connection (cell level and URA level): 

URA updating is a family of procedures that updates the UTRAN registration area of a UE when an RRC 
connection exists and the position of the UE is known on URA level in the UTRAN; 

handover is a family of procedures that adds or removes one or several radio links between one UE and UTRAN 
when an RRC connection exists and the position of the UE is known on cell level in the UTRAN. 
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Radio Bearer Control - Overview of Procedures 



5.1 Configurable parameters 



The following layer 1, MAC and RLC parameters should be able to configure by RRC. The list is not complete. 

- Radio bearer parameters, e.g. 

RLC parameters per RLC link (radio bearer), which may include e.g. PDU size and timeout values. Used by 
RLC. 

- Multiplexing priority per DCCH/DTCH. Used by MAC in case of MAC multiplexing of logical channels. 

- Transport channel parameters, e.g. 

Scheduling priority per transport channel. Used by MAC in case of layer 1 multiplexing of transport channels. 
Transport format set (TFS) per transport channel. Used by MAC and LI. 
Transport format combination set (TFCS) per UE. Used by MAC and LI. 

- Allowed subset of TFCS per UE. Used by MAC. 

CPCH access parameters per CPCH channel. Used by MAC and LI. 
Physical channel parameters, which may include e.g. carrier frequency and codes. Used by LI. 



5.2 Typical configuration cases 



The table below gives a proposal which main combination cases of parameter configuration that shall be supported, in 
terms of which parameters that shall be able to configure simultaneously (by one procedure). Note that the "Transport 
channel type switching" is not a parameter as such, it only indicates that switching of transport channel type may take 
place for that combination case. 

Table 1 : Typical configuration cases. 
An "X" indicates that the parameter can (but need not) be configured 



Parameter 


Layer 


A 


B 


c 


D 


E 


F 


Radio bearer 
parameters 


RLC parameters 


RLC 


X 














Logical channel 
multiplexing priority 


MAC 


X 












Transport 

channel 

parameters 


Transport channel 
scheduling priority 


MAC 


X 














TFS 


L1+MAC 


X 


X 












TFCS 


L1+MAC 


X 


X 












Subset of TFCS 


MAC 










X 


X 




Transport channel 
type switching 


MAC 


X 


X 


X 








Physical channel parameters 


L1 


X 


X 


X 


X 







Case A is typically when a radio bearer is established or released, or when the QoS of an existing radio bearer need to 
be changed. 

Case B is when the traffic volume of a radio bearer has changed so the TFS used on the DCH need to be changed, 
which may in turn affect any assigned set of physical channels. Another example is to make the UE use a new transport 
channel and at the same time supplying the TFS for that channel. 



£75/ 



3GPP TS 25.303 version 3.5.0 Release 1 999 9 ETSI TS 1 25 303 V3.5.0 (2000-09) 

Case C is when the traffic volume of one radio bearer has changed so that the used transport channel type is changed, 
e.g. from CELL_FACH to CELL_DCH or when the CPCH Set assigned to a UE is switched. This case includes the 
assignment or release of a set of physical channels. 

Case D is e.g. the change of used DL channelization code, when a DCH is currently used. No transport channel type 
switching take place. 

Case E is a temporary restriction and/or a release of restriction for usage of the TECS by the UE (total uplink rate). 

Case F is used to dynamically control the allocation of resources on uplink DCHs in the CRNC, using broadcast 
information such as transmission probability and maximum bit rate. 

5.3 RRC Elementary Procedures 

5.3.1 Category 1 : Radio Bearer Configuration 

The first category of procedures includes Case A and are characterized by: 

are executed upon request by higher layers and the parameter configuration is based on QoS; 

- affects LI , MAC and RLC. 

There are three RRC procedures included in this category: 

Radio Bearer Establishment: this procedure establishes a new radio bearer. The establishment includes, based 
on QoS, assignment of RLC parameters, multiplexing priority for the DTCH, CPCH Set assignment, scheduling 
priority for DCH, TFS for DCH and update of TECS. It may also include assignment of a physical channel(s) 
and change of the used transport channel types / RRC state. 

Radio Bearer Release: this procedure releases a radio bearer. The RLC entity for the radio bearer is released. 
The procedure may also release a DCH, which affects the TECS. It may include release of physical channel(s) 
and change of the used transport channel types / RRC state. 

Radio Bearer Reconfiguration: this procedure reconfigures parameters for a radio bearer (e.g. the signalling 
link) to reflect a change in QoS. It may include change of RLC parameters, change of multiplexing priority for 
DTCH/DCCH, CPCH Set assignment, change of DCH scheduling priority, change of TFS for DCH, change of 
TECS, assignment or release of physical channel(s) and change of used transport channel types. 

5.3.2 Category 2: Transport Cinannel Configuration 

The second category of procedures includes Case B and are characterized by: 

configuration of TFS for a transport channel and reconfiguration of TECS is done, but sometimes also physical 
channel parameters; 

- affects LI and MAC; 

switching of used transport channel(s) may take place. 

There is one RRC procedure included in this category: 

Transport Channel Reconfiguration: this procedure reconfigures parameters related to a transport channel 
such as the TFS. The procedure also assigns a TECS and may change physical channel parameters to reflect a 
reconfiguration of a transport channel in use. 

NOTE: It is expected that the configuration of TES/TECS needs to be done more seldom than the assignment of 
physical channel. A "pre-configuration" of TESATECS of a transport channel not in use can be done by 
this procedure, to be used after transport channel type switching when the physical channel is assigned. 

5.3.3 Category 3: Pinysical Cinannel Configuration 

The third category of procedures includes the cases C and D and are characterized by: 
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may assign or release a physical channel for the UE (which may result in transport channel type switching); 

may make a combined release and assignment (replacement) of a physical channel in use (which does not result 
in transport channel type switching / change of RRC state); 

affects mainly LI, and only the transport channel type switching part of MAC; 

the transport format sets (TFS and TFCS) are not assigned by this type of procedure. However, the UE can be 
directed to a transport channel, which TFS is already assigned to the UE. 

There is one RRC procedure included in this category: 

Physical Channel Reconfiguration: this procedure may assign, replace or release a set of physical channels 
used by an UE. As a result of this, it may also change the used transport channel type (RRC state). For example, 
when the first physical channel is assigned the UE enters the DCH/DCH state. When the last physical channel is 
released the UE leaves the CELL_DCH state and enters a state (and transport channel type) indicated by the 
network. A special case of using this procedure is to change the DL channelization code of a dedicated physical 
channel. 

NOTE: The procedure does not change the active set, in the downlink the same number of physical channels are 
added or replaced for each radio link. 

5.3.4 Category 4: Transport Format Combination Restriction 

The fourth category of procedures includes Case E and are characterized by: 

does only control MAC by means of the transport format combinations that may be used within the set without 
affecting LI. 

There is one RRC procedure included in this category: 

Transport format combination control: the network uses this procedure towards an UE, to control the used 
transport format combinations in the uplink within the transport format combination set. 

5.3.5 Category 5: Uplink Dedicated Cinannel Control in CRNC 

The fifth category of procedures includes Case F and are characterized by: 

does control UE MAC by means of broadcasting transmission probability and maximum total bit rate that shall 
be used for uplink DCHs, which are under control by this procedure. 

There is one RRC procedure included in this category: 

- Dynamic Resource Allocation Control of Uplink DCHs: the network uses this procedure towards all UEs, to 
control the probability of transmission and the maximum total bit rate used by uplink DCHs, which are under 
control by this procedure. 



6 Examples of procedures 

These sequences are examples and do not provide a comprehensive set of all different scenarios. 

In cases where the logical and / or transport channel for a given message is known, it can be shown in front of the 
message name {LogicaljCh: TransportjCh: Message). For example: DCCH:RACH:Acknowledged Data indicates a 
data message on DCCH mapped onto RACH. Either logical or transport channel can be omitted, if it is unspecified for 
the message. 
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6.1 RRC Connection Establishment and Release Procedures 
6.1.1 RRC connection establishment 

RRC connection establishment (see 151) is shown in figure 1 (protocol termination for common channels is shown 
according to former case A, case C can be found for comparison in annex A). The RRC layer in the UE leaves the idle 
mode and initiates an RRC connection establishment by sending an RRC Connection Request message using the MAC 
SAP for the CCCH logical channel. MAC transmits the L3 message on the RACH transport channel. 

On the network side, upon the reception of RRC Connection Request, the RRC layer performs admission control, 
assigns an s-RNTI for the RRC connection and selects radio resource parameters (such as transport channel type, 
transport format sets etc). If a DCH is to be established, CPHY-RL-Setup and CPHY-TrCH-Config request primitives 
(transmitted as one RADIO LINK SETUP PDU) are sent to all Node Bs which would be involved in the channel 
establishment. The physical layer operation is started and confirmation primitives are returned from each Node B. RRC 
configures parameters on layer 2 to establish the DCCH logical channel locally. The selected parameters including the 
RNTI, are transmitted to the UE in an RRC Connection Setup message using the MAC SAP for the CCCH logical 
channel. 

Upon reception of the RRC Connection Setup message, the RRC layer in the UE configures the LI and L2 using these 
parameters to locally establish the DCCH logical channel. In case of DCH, layer 1 indicates to RRC when it has 
reached synchronisation. 

The RLC signalling link is locally established on both sides. The establishment can be mapped on either RACH / 
EACH, RACH+FAUSCH / EACH or DCH by MAC. When the UE has established the RLC signalling link, it transmits 
an RRC Connection Setup Complete message to the network using acknowledged mode on the DCCH. 
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Figure 1 : RRC connection establishment (with common channel termination case A) 



£75/ 



3GPP TS 25.303 version 3.5.0 Release 1999 



13 



ETSI TS 125 303 V3.5.0 (2000-09) 



6.1.2 UE Initiated Signalling Connection Establishment 

NOTE 1 : In case additional UE capability information is needed at RRC Connection Setup, it is transmitted in the 
RRC Connection Setup Complete message. 

The sequence in figure 2 shows the establishment of the first Signalling Connection for the UE, initiated by the UE. 

RRC Signalling Connection Establishment is requested by the non access stratum in the UE with a primitive over the 
Dedicated Control (DC) SAP. The primitive contains an initial message to be transferred transparently by RRC to the 
non-access stratum entity on the network side. 

NOTE 2: The initial NAS message could for a GSM based Core Network be e.g. CM Service Request, Location 
Update Request etc. 

If no RRC connection exists, the RRC layer makes an RRC connection establishment, which includes the transmission 
of UE capability information. When the RRC connection establishment is completed, the signalling connection 
establishment can be resumed. 

The initial message from NAS is transferred in the RRC message "Direct Transfer" using acknowledged mode on the 
DCCH, to the network, where it is passed on with an RRC Signalling Connection Establish IND primitive over the 
DC-SAP. 

When the initial NAS message has been transferred successfully, as indicated by the RLC-Data-CNF primitive in the 
UE, the Signalling Connection Establishment is confirmed by the UE-RRC. 



Uu lub 



UE-RRC 



UE-RLC 



RRC Signalling 
Connection 

Establishment 
Requested 



SRNC-RLC 



RRC Connection Establishment 



RLC-Data-REQ 



Direct Transfer 



RLC-Data-CNF 



Confirm RRC 

Signalling 

Connection 

Establishment 



DCCH: A(l<nowle 



Dirict Iran 
DCCH: Data 



;fer 
ack 



3ed Data 



SRNC-RRC 



RLC-Data-IND 



Direct Transfer 



Indicate RRC 

Signalling 

Connection 

Establishment 



Figure 2: UE initiated Signalling Connection Establishment 

6.1.3 Normal RRC Connection Release 

A normal RRC Connection Release procedure is initiated on the network side by an RRC Signalling Connection 
Release request for the last Signalling Connection of a UE. The procedure is slightly different depending on whether the 
UE has dedicated physical channel(s) allocated. 
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The RRC layer entity in the network issues an RRC CONNECTION RELEASE message using unacknowledged mode 
on the DCCH. Upon reception of this message the UE-RRC sends an RRC Signalling Connection Release Indication 
primitive to NAS The UE replies with an RRC CONNECTION RELEASE COMPLETE message, which is sent in 
unacknowledged-mode on the dedicated channel. To improve the reliability of the message, quick repeat on RRC-level 
can be used. The UE will then proceed to release RLC(s), MAC and the radio link(s) after which the UE RRC enters 
Idle Mode. 

The primary method to detect the release of the signalling link in the NW is the RRC CONNECTION RELEASE 
COMPLETE-message from the UE. Should the message be lost despite the use of quick repeat, the release of the 
signalling link is detected by the out-of-sync primitive from either Node-B LI or RNC-Ll to RNC RRC. After 
receiving this primitive, the RNC -RRC layer releases L2 and LI resources on the network side and enters the idle mode. 

6.1 .3.2 RRC Connection Release without Dedicated Physical Channel 

The RRC layer entity in the network issues an RRC CONNECTION RELEASE message using unacknowledged or 
acknowledged mode on the DCCH. Upon reception of this message the UE-RRC sends an RRC Signalling Connection 
Release Indication primitive to NAS and an RRC CONNECTION RELEASE COMPLETE message to UTRAN using 
acknowledged mode on the DCCH. 

After receiving the RRC CONNECTION RELEASE COMPLETE message the network RRC layer releases L2 
resources, sends an RRC Signalling Connection Release confirmation to DC-SAP and goes to Idle Mode (more 
precisely: only the RRC entity dedicated to this UE goes to Idle Mode). 
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6.2 Radio Bearer Control Procedures 
6.2.1 Radio Bearer Configuration 
6.2.1 .1 Radio Bearer Establishment 

The procedures for establishing radio bearers may vary according to the relation between the radio bearer and a 
dedicated transport channel. Depending on the QoS parameters, there may or may not be a permanently allocated 
dedicated channel associated with the RB. Circuit-switched bearers, or bearers classified as real-time services typically 
need a permanent association to a DCH to meet the delay requirements. Packet-switched bearers, or bearers classified as 
non-real-time services can in many cases be served as best-effort, requesting capacity from an associated DCH based on 
need. 

When establishing an RB together with a DCH, the DCH may be attached to either a newly activated physical channel 
or it may be accommodated by modifying an existing physical channel. The modification is further broken down into 
two different options: synchronised and unsynchronised. If the old and new physical channel settings are compatible 
(TFCI etc.) in the sense that executing the modification in the NW and the UE with arbitrary timing does not introduce 
transmission errors, the unsynchronised procedure can be applied. If the old and new settings are incompatible, due to 
e.g. assignment of the same TFCI value to a new set of physical layer configuration, the synchronised procedure must 
be used. 

6.2.1 .1 .1 Radio Bearer Establishment with Dedicated Physical Channel Activation 

The procedure in figure 5 is applied when a new physical channel needs to be created for the radio bearer. A Radio 
Bearer Establishment is initiated when an RB Establish Request primitive is received from the DC-SAP on the network 
side of the RRC layer. This primitive contains a bearer reference and QoS parameters. Based on these QoS parameters, 
LI and L2 parameters are chosen by the RRC entity on the network side. 

The physical layer processing on the network side is started with the CPHY-RL-Setup request primitive issued to all 
applicable Node Bs. If any of the intended recipients is / are unable to provide the service, it will be indicated in the 
confirmation primitive(s). After setting up LI including the start of tx / rx in Node B, the NW-RRC sends a RADIO 
BEARER SETUP message to its peer entity (acknowledged or unacknowledged transmission optional for the NW). 
This message contains LI, MAC and RLC parameters. After receiving the message, the UE-RRC configures LI and 
MAC. 

When LI synchronisation is indicated, the UE sends a RADIO BEARER SETUP COMPLETE message in 
acknowledged-mode back to the network. The NW-RRC configures MAC and RLC on the network side. 

After receiving the confirmation for the RADIO BEARER SETUP COMPLETE, the UE-RRC creates a new RLC 
entity associated with the new radio bearer. The applicable method of RLC establishment may depend on RLC transfer 
mode. The RLC connection can be either implicitly established, or explicit signalling can be applied. 

Finally, an RB Establish Indication primitive is sent by UE-RRC and an RB Establish Confirmation primitive is issued 
by the RNC-RRC. 
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Figures: Radio Bearer Establishment with Dedicated Physical Channel Activation 



£75/ 



3GPP TS 25.303 version 3.5.0 Release 1999 19 

6.2.1.1.2 Radio Bearer Establishment with Unsynchronised Dedicated Physical Channel Modification 
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Figure 6: Radio Bearer Establishment with Unsynchronised Dedicated Physical Channel Modification 
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The establishment of a radio bearer, when unsynchronised physical channel modification is applicable, is shown in 
figure 6. If the old and new physical layer configurations are compatible in the sense that they can coexist in the peer 
entities, an unsynchronised procedure for radio bearer establishment can be applied. In this case no fixed activation time 
is required. 

The modifications on the physical layer in the network are done in response to an CPHY_ modify request. Failure to 
comply is indicated in the confirmation primitive. In an error-free case the RADIO BEARER SETUP message on L3 is 
transmitted. Acknowledged or unacknowledged transmission is a network option. Configuration changes on the UE- 
side proceed after this message has been received. Reception of the RADIO BEARER SETUP COMPLETE message 
triggers configuration changes in MAC and RLC in the network. 

6.2.1 .1 .3 Radio Bearer Establishment with Synchronised Dedicated Physical Channel 

Modification 

In this case the CPHY-RL-Modify request doesn't immediately cause any changes in the physical layer configuration, it 
only checks the availability of the requested configuration and makes a "reservation". After the confirmations have been 
received from all applicable Node Bs, the RRC chooses the appropriate "activation time" when the new configuration 
can be activated. This information is signalled to MAC, RLC and also the physical layer (CPHY_Commit request 
primitive). 

After the RADIO BEARER SETUP message (acknowledged transmission on L2 required) between peer L3 entities the 
setup proceeds on the UE-side. The new configuration is now available both on the UE and the network side, and at the 
scheduled activation time the new configuration is assumed by all applicable peer entities. 

In case the old and the new physical channel configurations are incompatible with each other (due to different DPCCH 
format, TFCI patterns or similar differences), the modification on physical layer and L2 require exact synchronisation 
between the UE and the NW, as shown in figure 7. 
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Figure?: Radio Bearer Establishment with Synchronised Dedicated Physical Channel Modification 
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6.2.1 .1 .4 Radio Bearer Establishment without Dedicated Physical Channel 
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Figure 8: Radio Bearer Establishment without Dedicated Physical Channel 
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For some radio bearers dedicated radio resources are not permanently associated. Therefore the setting up of the 
physical resource is separate from the actual radio bearer setup, which involves only RLC and MAC. 

MAC can be initially configured to operate either on existing dedicated transport and physical channels or on common 
channels. 

6.2.1 .1 .5 Radio Bearer Establishment with CPCH Channel Allocation 

When the RNC determines the need to assign CPCH UL resources to a UE, the RNC sends an RB Setup message to the 
UE. Since the CPCH physical parameters are broadcast in the BCCH, the RB Setup message does not include a DPCH 
part. The Transport Channel information includes the CPCH set (CPCH Set ID#) to which the UE is to be assigned. 
MAC entities are configured: MAC-D and MAC-C/SH in the UE, MAC-C/SH in the CRNC, and MAC-D in the SRNC. 
Node B MAC controls access to the individual CPCH channels in the CPCH set. However, Node B MAC does not 
require configuration, since it was configured to control the CPCH set when the CPCH set was initially allocated to that 
cell. The Node B MAC can function independently of the number of UEs assigned to the CPCH set. Once the RB setup 
is complete, the UE may access the CPCH when the logical channel for this RB next presents data to send in the uplink 
direction. 

The message flow diagram for RB establishment for CPCH is similar to the RB establishment without Dedicated 
Physical Channel (see subclause 6.2.1.1.4). 
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Figure 9: Radio Bearer Establishment with CPCH Channel Allocation 
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6.2.1 .2 Radio Bearer Release 

Similar as for Radio Bearer Establishment procedure, the Radio Bearer Release can include physical channel 
modification or physical channel deactivation depending on the differences between new and old QoS parameters. 
These can also be both synchronised and unsynchronised. 

The Radio Bearer Release procedure is initiated when the release is requested from the RRC layer on the NW side. This 
request contains a bearer reference, and on retrieval a RB Release Confirm primitive is immediately returned to the 
Non-Access Stratum. 

New LI and L2 parameters may be chosen for remaining radio bearers if any. A RADIO BEARER RELEASE message 
is sent from the RRC layer in the network to its peer entity in the UE. This message includes possible new LI, MAC 
and RLC parameters for remaining radio bearers and indentification of the radio bearer to be released (note). An RB 
Release Indication is sent by the UE-RRC. 

NOTE: In synchronised case a specific activation time would be needed for the change of LI and L2 
configuration to avoid data loss. 

The RRC on the UE side configures LI and MAC, and releases the RLC entity associated to the released radio bearer. 
After receiving a RADIO BEARER RELEASE COMPLETE message from the UE, the NW-RRC does a similar 
reconfiguration also on the network side. 

6.2.1 .2.1 Radio Bearer Release with Unsynchronised Dedicated Physical Channel 

Modification 

The example in figure 10 shows the case where release can be executed as an unsychronised physical channel 
modification, i.e. without physical channel deactivation. 

After notifying upper layers of the release, a RADIO BEARER RELEASE message (acknowledged or unacknowledged 
transmission optional for the network) is sent to the UE triggering the reconfiguration in the UE. When this is finalised 
the UE sends a RADIO BEARER RELEASE COMPLETE message to the network, after which the reconfiguration is 
executed in the network. 
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Figure 10: Radio Bearer Release with Unsynchronised Dedicated Physical Channel Modification 
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6.2.1 .3 Radio Bearer Reconfiguration 

For Radio Bearer Reconfiguration, both synchronised and unsynchronised procedures are applicable. The 
unsynchronised procedure is shown as an example. 

6.2.1.3.1 Unsynchronised Radio Bearer Reconfiguration 

Because of the unsynchronised nature of the procedure in figure 11, there is no activation time and no separate commit 
request for the Node B physical layer is needed. The possibility for executing the requested modification will be 
reported in the confirmation primitives from the physical layer. If the modification involves the release of an old 
configuration, the release can be postponed to the end of the procedure. After the reception of a RADIO BEARER 
RECONFIGURATION from the RNC-RRC (acknowledged or unacknowledged transmission optional for the network), 
the UE executes the modifications on LI and L2. 

Upon reception of a RADIO BEARER RECONFIGURATION COMPLETE message from the UE-RRC, the NW-RRC 

executes the modifications on LI and L2. Finally the old configuration, if any, is released from Node B-Ll. 
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Figure 11: Unsynchronised Radio Bearer Reconfiguration 
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6.2.2 Transport Channel Reconfiguration 

For transport channel reconfiguration, both synchronised and unsynchronised procedures are appHcable. 

6.2.2.1 Unsynchronised Transport Format Set Reconfiguration 

Figure 12 illustrates an example of a procedure for a change of the Transport Format Set for one transport channel. This 
is done with the Transport Channel Reconfiguration procedure. 

A change of the transport format set for a transport channel is triggered in the RRC layer in the network. A 
TRANSPORT CHANNEL RECONFIGURATION message is sent from the RRC layer in the network to its peer entity 
(acknowledged or unacknowledged transmission is a network option). This message contains the new transport format 
set and a new transport format combination Set, i.e. new parameters for LI and MAC (note). When this message is 
received in the UE a reconfiguration of LI and MAC is done. A similar reconfiguration is also done on the network side 
after the reception of a TRANSPORT CHANNEL RECONFIGURATION COMPLETE message. 

NOTE: In a synchronised procedure a specific activation time is needed for the change of LI and L2 
configuration to avoid data loss. 

During the reconfiguration of the transport format set for a transport channel, radio traffic on this channel could be 
halted temporarily since the UE and the network are not necessarily aligned in their configuration. This traffic can 
resume after the COMPLETE-message. 
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Figure 12: Unsynchronised Transport Format Set Reconfiguration 
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Figure 13: Asymmetric DCH Reconfiguration 
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NOTE: This procedure is considered for Release 00. 

The RNC has initially sent one or more channel configurations (cfgl, cfg2, cfg3...) to each Node B and to the UE, 
e.g. at RB Setup. 

When a DCH configuration is to be modified, the RNC sends a TRANSPORT CHANNEL RECONFIGURATION 
message to the UE, indicating the new configuration to be applied (e.g. change from cfg3 to cfg2). Each Node B can 
then configure its physical layer to receive in the new configuration mode at a given radio frame number. 

Upon reception of the TRANSPORT CHANNEL RECONFIGURATION message, the UE reconfigures uplink LI and 
L2 resources and starts to transmit data with the new configuration. In downlink, the UE can switch to the new 
configuration after a certain time which corresponds basically to the round trip delay. The UE may also avoid any data 
loss by temporarily performing double decoding. 

When a Node B detects the new configuration at the specified radio frame, this is signalled to the RNC over the lub. If 
the expected configuration is not detected, then the Node B can revert back to the old configuration. When the RNC 
detects, from one or more Node Bs, that the new configuration is applied by the UE on the uplink, it starts sending to 
every Node B, downlink DCH lub frames with an indication of the new mode to be applied. 

6.2.3 Physical Channel Reconfiguration 

For physical channel reconfiguration, both synchronised and unsynchronised procedures are applicable. 

6.2.3.1 UE-Originated DCH Activation 

Figure 14 illustrates an example of a procedure for a switch from common channels (CELL_FACH) to dedicated 
(CELL_DCH) channels. 

In the UE the traffic volume measurement function decides to send a MEASUREMENT REPORT message to the 
network. In the network this measurement report could trigger numerous different actions. For example the network 
could do a change of transport format set, channel type switching or, if the system traffic is high, no action at all. In this 
case a switch from CELL_FACH to CELL_DCH is initiated. 

Whether the report should be sent with acknowledged or unacknowledged data transfer is configured by the network. 

First, the modifications on LI are requested and confirmed on the network side with CPHY-RL-Setup primitives. 

The RRC layer on the network side sends a PHYSICAL CHANNEL RECONFIGURATION message to its peer entity 
in the UE (acknowledged or unacknowledged transmission optional to the network). This message is sent on DCCH 
mapped to EACH. The message includes information about the new physical channel, such as codes and the period of 
time for which the DCH is activated (note). 

NOTE: This message does not include new transport formats. If a change of these is required due to the change of 
transport channel, this is done with the separate procedure Transport Channel Reconfiguration. This 
procedure only handles the change of transport channel. 

When the UE has detected synchronisation on the new dedicated channel L2 is configured on the UE side and a 
PHYSICAL CHANNEL RECONFIGURATION COMPLETE message can be sent on DCCH mapped on DCH to RRC 
in the network. Triggered by either the NW CPHY_sync_ind or the L3 complete message, the RNC-Ll and L2 
configuration changes are executed in the NW. 

When applying the FAUSCH, the "DCCH: RACH: MEASUREMENT REPORT" is replaced by a "DCCH: FAUSCH: 
DCH REQUEST" message that is transmitted on the FAUSCH in unacknowledged mode. In this case rather than giving 
a measurement report for the NW to process, the FAUSCH indicates a request for a DCH of predefined capacity. 
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Figure 14: UE-Originated DCH Activation 
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Figure 15: UE-terminated synchronised DCH IVIodify 
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Figure 15 illustrates an example of a synchronised procedure for DCH modification. Triggering of this procedure could 
for example be accomplished by an inactivity timer. The procedure can e.g. release all transport formats of a radio 
bearer without releasing the DCH, due to another bearer using it. The synchronised procedure is applied in the case 
when the old and new configurations are not compatible e.g. change of channelization code. 

After the CPHY-RL-Modify requests have been confirmed, an activation time is chosen by NW-RRC. After deciding 
upon the activation time, the NW-RRC sends a PHYSICAL CHANNEL RECONFIGURATION message as 
acknowledged data transfer to the UE. In both uplink and downlink this message is sent on DCCH mapped on DCH. 

After reception the UE reconfigures LI and L2 to DCH resources. If a complete message is used it would be sent on 
DCCH mapped on DCH. In the unsynchronised case this message could trigger a modification of LI and L2 resources 
in the network associated with the dedicated channel. 

6.2.3.3 UE-terminated DCH Release 

Figure 16 illustrates an example of a procedure for a switch from dedicated (CELL_DCH) to common (CELL_FACH) 
channels. All DCHs used by a UE are released and all dedicated logical channels are transferred to CELL_FACH 
instead. Triggering of this procedure could for example be an inactivity timer. 

A switch from DCH to common channels is decided and a PHYSICAL CHANNEL RECONFIGURATION message is 
sent (acknowledged or unacknowledged data transfer is a network option) from the RRC layer in the network to the UE. 
This message is sent on DCCH mapped on DCH. 

NOTE 1 : This message does not include new transport formats. If a change of these is required due to the change of 
transport channel, this is done with the separate procedure Transport Channel Reconfiguration. This 
procedure only handles the change of transport channel. 

If the loss of LI sync is used to detect in the NW that the UE has released the DCHs, as is one possibility in the figure, 
then there may be a need to configure the Node B-Ll to a short timeout for detecting loss of sync. This is presented by 
the CPHY-Out-of-Sync-Config primitives in the figure. 

After reception the UE reconfigures LI and L2 to release old DCH resources. The PHYSICAL CHANNEL 
RECONFIGURATION COMPLETE message to the network is here sent on DCCH mapped on RACH (message 
acknowledgement on EACH). This message triggers a normal release of LI and L2 resources in the network associated 
with the dedicated channel. 

NOTE 2: When a Switch to CELL_FACH is done it is important to free the old code as fast as possible so that it 

can be reused. Therefore instead of waiting for the Physical Channel Rreconfiguration Complete message 
the network can reconfigure LI and L2 when the acknowledged data confirmation arrives and the 
network is sure that the UE has received the Physical Channel Reconfiguration message. To be even more 
certain that the UE has released the old DCH resources the network can wait until after the Out of sync 
Indication from LI. 

These steps including a timer starting when the Physical Channel Reconfiguration is sent, gives the 
network four different indications that the released DCH is really released, and that resources can be 
reused. 
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Figure 16: UE-terminated DCH Release 
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Figure 17: Transport Format Combination Limitation 

Figure 17 illustrates an example of a Transport Format Combination Control procedure. A congestion situation occurs 
and allowed transport format combinations are restricted temporarily. When the congestion is resolved the restriction is 
removed. 

This procedure is initiated with a Transport Format Combination Control message from the network to the UE 
(acknowledged, unacknowledged or transparent transmission optional to the NW). This message contains a subset of 
the ordinary Transport Format Combination Set. The UE then continues with a reconfiguration of MAC. MAC sees the 
TFC subset as a completely new set. 

Further, after a while when the congestion is resolved a new Transport Format Combination Control message is sent to 
the UE from the RRC layer in the network. This message contains a subset that is the entire original set. Again, the UE 
reconfigures the MAC. 
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Figure 18: Dynamic Resource Allocation Control of Uplink DCHs 
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Figure 18 illustrates an example of a Dynamic Resource Allocation Control procedure of uplink DCHs. The CRNC 
regularly broadcasts the following parameters: 

transmission probability ptr, which indicates the probability for a UE to be allowed to transmit on its DCHs, 
which are under control by this procedure, during the next period Tvandity; 

maximum total bit rate allowed to be used by the UE on its DCH which are under controlled by this procedure, 
during the next allowed period Tyaiidity 

Besides these parameters, the RNC has allocated the following parameters to the UE: 

transmission time validity, Tvaiidity, which indicates the time duration for which an access for transmission is 
granted; 

- reaccess time Tjeti-y, which indicates the time duration before retrying to access the resources, in case 
transmission has not been granted. 

This procedure is initiated with a Dynamic Uplink Resource Allocation Control message regularly broadcast by the 
CRNC. It applies to all UEs having DCHs that can be controlled dynamically. The UEs have to listen to this message 
prior to transmission on these DCHs. The UE RRC checks whether transmission is allowed, and then reconfigures 
MAC with a new subset of TECS derived from the maximum total bit rate parameter. This TECS subset shall control 
only the DCHs which are under control by this procedure. The UE RRC procedure shall be mandatory for all UEs 
supporting high bit rate NRT services. 

In case of soft handover on the uplink DCH, The UE is requested either to listen to broadcast information from its 
primary cell (the one with the lowest pathloss), or from all cells involved in its Active Set, depending on its class. In the 
latter case, the UE is expected to react according to the stricter control information. 
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Figure 19: Variable Rate Transmission of Uplink DCHs 
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Figure 19 illustrates an example of the Variable Rate Transmission procedure of uplink DCHs. With this procedure the 
QoS of service with variable rate can be maintained and unnecessary interference can be avoided by a temporary 
reduction of the data rate within the TFCS. 

When a connection for a variable rate service is established the RRC assigns the TFCS to MAC. At the radio bearer set- 
up procedure the maximum allowable Tx power can also be set for each user if it shall be different from the UE 
capability class. 

With the CPHY-Measurement-REQ the power thresholds will be set to the UE. If during a transmission the allowable 
transmit power is above the set threshold the event will be signalled to the MAC that will decrease the data rate within 
the set TFCS at the next transmission time interval. In the UE, the PDUs that can not be transmitted in a TTI (i.e. MAC 
has indicated that some of the available PDUs can not be transmitted) shall be buffered according to the discard 
configuration set by RRC. 



When channel conditions improve and the averaged transmission power falls below the allowable transmission power 
the physical layer indicates this event to the MAC. If there is enough data to be sent, the MAC in response increases the 
data rate by increasing the number of transport blocks delivered to LI and the physical layer increases the total 
transmission power to the UE by the predefined amount. This allows the data that was buffered during bad channel 
conditions to be delivered to the UTRAN. 
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Figure 20: Example of acknowledged-mode data transmission on DSCH 
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Figure 20 shows an example of acknowledged-mode data transmission on DSCH associated with a DCH. First RLC in 
SRNC requests data transmission locally from MAC-d. MAC-d routes the request either locally or across the lur to 
MAC-c/sh in CRNC, where DSCH transmission scheduling takes place. MAC-c/sh determines the TFI for the data 
('TFI2') and requests data transmission across lub from the physical layer in Node B. At the same time data for an 
associated dedicated channel may arrive in Node B. 

All TFIs for DCHs (e.g. 'TFIl')) are translated into TFCI(fieldl). TFCI(field2) carries corresponding information for the 
DSCH. TFCI(fieldl) and TFCI(field2) are combined in the physical layer using 'hard' split of the TFCI-word and 
transmitted on the DPCCH (dedicated physical control channel) of the associated DPCH (dedicated physical channel). 
The DSCH data is transmitted separately on the PDSCH (physical downlink shared channel). TFCI(field2) is used to 
decode DSCH data, which is then forwarded through MAC-c/sh and MAC-d to the receiving RLC. An 
acknowledgement is eventually sent by the UE-RLC mapped to a DCH, unless the DCH is released before the 
acknowledgement. 

6.3.2 Acknowledged-mode data transmission on DSCH using logical split 
ofTFCI-word 

NOTE: For release-99 this example is only valid in the case where SRNC = CRNC. 

Figure 21 shows an example of acknowledged-mode data transmission on DSCH. First RLC in SRNC requests data 
transmission from MAC-d. MAC-d passes the data on to MAC-c/sh, which schedules the DSCH transmission and 
determines the TFI2 for the data. TFCI(field2) and CFN (connection frame number) for transmission are given back to 
MAC-d. 

MAC-c/sh transmits the DSCH data while MAC-d transmits all TFIs synchronised with the transmission of any DCH 
data and TFIs intended for transmission in the same frame. TFCI(field2)for the DSCH and TFCI(fieldl)for the DCH are 
combined into the same TFCI on the physical layer using 'logical' split of TFCI-word and transmitted on the DPCCH 
(dedicated physical control channel) of the associated DPCH (dedicated physical channel). The DSCH data is 
transmitted separately on the PDSCH (physical downlink shared channel). TFCI(field2)is used to decode DSCH data, 
which is then forwarded through MAC-c/sh and MAC-d to the receiving RLC. An acknowledgement is eventually sent 
by the UE-RLC mapped to a DCH, unless the DCH is released before the acknowledgement. 
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Figure 21 : Example of acknowledged-mode data transmission on DSCH 
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Figure 22: Example of data transmission on CPCIH (page 1 of 2) 
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Figure 23: Example of data transmission on CPCIH (page 2 of 2) 
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Figure 22 shows an example of data transmission on CPCH. It is assumed that RLC acknowledged or unacknowledged 
transmission modes are applied for all logical channels mapped to CPCH. 

CPCH transmission is applied in the Connected mode RRC state CELL_FACH with CPCH resources assigned to the 
UE. The UE needs to be configured for CPCH transmission via a respective RRC procedure (e.g. with RADIO 
BEARER SETUP or TRANSPORT CHANNEL RECONFIGURATION messages). 

Upon reception of a data transmission request from RLC, MAC first requests CPCH channel status information from 
the physical layer. It is assumed that CPCH channel status information is broadcast on the CSICH physical channel 
using the same DL channelisation code as AP-AICH. The status information provides an indication of the maximum 
available data rate on PCPCH resources when Channel Assignment (CA) is active. When Channel Assignment is not 
active, then UE Channel Selection is employed. In this case the status information provides indication of the availability 
of each defined PCPCH. In either case, the channel status information is converted into a set of transport formats that 
are allowed to be employed at that given time. Whether channel assignment is active or not shall be indicated via 
System Information message. Current assumption is that the conversion of CPCH status information into Transport 
Formats is a LI internal function. 

Based on the permitted transport formats and the data available for transmission, MAC selects a desired transport 
format for CPCH access request. The MAC CPCH transmission control procedure is started by performing the 
persistency check based on persistence value received from RRC. When persistence check is passed, the physical 
CPCH transmission procedure is initiated by sending of a PHY-Access-REQ primitive. The PCPCH transmission 
procedure starts with an access preamble power ramping cycle. MAC then waits for status indication from LI via 
PHY-Status-IND primitive. When acquisition of the access preamble is indicated on AP-AICH the CD preamble is sent 
on PCPCH. Reception of the CD preamble in Node B is indicated on CD-ICH to the UE. If Channel Assignment is 
active, channel assignment information is simultaneously transmitted on CD/CA-ICH. Layer 1 provides status 
indication to MAC indicating the CD or CD/CA information. The CA information defines in the UE on LI the PCPCH 
to use for the power control preamble and the message part. Then MAC builds the CPCH transport block set to be 
transmitted via PHY-Data-REQ with the appropriate Transport Format that may differ from the requested transport 
format. 

After the or 8 slot period for the power control preamble, the first Transport Block Set (first TTI) of the message is 
transmitted. 

While the first transport block is being sent. Node B layer 1 sends the start of message indicator whereby upon the 
reception of this start of message indicator UE can know if it uses correct CPCH channel or not. If UE does not receive 
the start of message indicator within certain period, it stops its message transmission immediately. Otherwise, UE 
continues the transmission. 

Data transmission on CPCH is continued until all available data has been sent or until the maximum frame length 
[NF_max] is reached. If the UE has no more data to send prior to NF_max, the UE can notify the UTRAN that no more 
frames will be transmitted prior to the maximum frame length [NF_max] on the CPCH by using End of Transmission 
indication. The acknowledgements from RLC entities in SRNC are routed by the NW MAC to the UE RLC entities 
using the EACH DL transport channel. 

In figure 22, the events between points A and B define the CPCH transmission procedure for the first TTI. In figure 23, 
events from point C to D describe the CPCH transmission procedure for each subsequent TTI. In figure 23, the events 
from point E to F describe the stop procedure of CPCH transmission when the UE has no more data to send prior to the 
maximum frame length [NF_max]. In this case a stop of CPCH transmission can take place for the release of CPCH 
transmission prior to NF_max. The stop of CPCH transmission is indicated by the PHY-DATA-REQ primitive 
indicating the 'end of transmission' event by setting zero sized Transport Block as indicated by TFI. 

On request from RRC at the network side, for example, for reacting on temporary overload conditions, an emergency 
stop of CPCH transmission can take place. The emergency stop is indicated by the PHY-STATUS-IND primitive. 

Note also that in the case of transmit power restrictions that are also indicated via PHY-STATUS-IND primitive, 
restrictions on Transport Format selections may apply at any time during CPCH transmission. 

6.3.4 Data transfer on USCH (TDD only) 

In figure 24 a data transfer procedure on USCH is presented. It is assumed that the RB establishment has been 
performed for example with the RB Establishment procedure without Dedicated Physical Channel as illustrated in 
subclause 6.2. LL4 and that the RB is mapped on the USCH and DSCH transport channels. Use of the USCH is 
possible with or without an associated DCH. 



£75/ 



3GPP TS 25.303 version 3.5.0 Release 1999 



48 



ETSI TS 125 303 V3.5.0 (2000-09) 



In the UE the traffic measurement function decides to send a Capacity Request to the network using the SHCCH logical 
channel mapped on the RACH or USCH. In the C-RRC the USCH/DSCH scheduUng function will decide to allocate 
physical resources to this logical channel and RRC in C-RNC sends a PhyShChAllocation to its peer entity in the UE. 
This message specifies the physical resources and the period of time the MAC-c/sh can transfer the data on the USCH 
transport channel. 

Both RRC in the CRNC and the UE configure their respective Layer 1 and MAC for the data transfer on the USCH and 
at the specified time MAC-c/sh in the UE conveys the data using the specified PUSCH resources. 

This operation may be repeated several times till the RLC buffer is empty. 

In the diagram it is assumed that the PhyShChAllocation has allocated additionally to the PUSCH resources some 
PDSCH resources, so that at the time specified in the allocation message both RRC in the CRNC and the UE configure 
their respective Layer 1 and MAC for the data transfer on the DSCH and at the specified time MAC-c/sh in the C-RNC 
conveys the acknowledgement message of the UTRAN RLC to its UE peer entity using the specified PDSCH resources. 

Transmitting the acknowledgement message via EACH is also possible. 
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Figure 24: Data transfer on USCH 
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6.3.5 Data transfer on DSCH (TDD only) 

In figure 25 a data transfer procedure on DSCH is presented. It is assumed that the RB establishment has been 
performed for example with the RB Establishment procedure without Dedicated Physical Channel as illustrated in 
subclause 6.2.1.1.4 and that the RB is mapped on the USCH and DSCH transport channels. 

Use of the DSCH is possible with or without an associated DCH. 

In the C-RRC the USCH/DSCH scheduling function will decide to allocate physical resources in the downlink and RRC 
in C-RNC sends a PhyShChAUocation message to its peer entity in the UE using SHCCH mapped on the EACH or 
DSCH. This message specifies the physical resources and the period of time the MAC-c/sh can transfer the data on the 
DSCH transport channel. 

Both RRC in the CRNC and the UE configure their respective Layer 1 and MAC for the data transfer on the DSCH and 
at the specified time MAC-c/sh in the C-RNC conveys the data using the specified PDSCH resources. 

This operation may be repeated several times till the RLC buffer is empty. 

In the diagram it is assumed that the PhyShChAUocation has allocated additionally to the PDSCH resources some 
PUSCH resources, so that at the time specified in the allocation message both RRC in the CRNC and the UE configure 
their respective Layer 1 and MAC for the data transfer on the USCH and at the specified time MAC-c/sh in the UE 
conveys the acknowledgement message of the UE to its C-RNC peer entity using the specified PUSCH resources. 

Transmitting the acknowledgement message via RACH is also possible. 
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Figure 25: Data transfer on DSCH 



6.4 RRC Connection mobility procedures 

The RRC handover protocol must be common for the FDD and TDD modes. This means that the same protocol must 
support all the following handover procedures. 

6.4.1 Handover IVIeasurement Reporting 

Figure 26 illustrates an example where a measurement control and a measurement report procedure is used for handover 
measurements. The NW RRC requests the UE to start measurements and reporting with a MEASUREMENT 
CONTROL message. The message includes an indication of a measurement type (e.g. intra-frequency measurement), 
the radio links to evaluate, the reporting criteria and a measurement identity number. The UE configures LI to start 
measurements. When measurement reporting criteria are fulfilled the UE sends a MEASUREMENT REPORT message. 
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Figure 26: Handover measurement reporting 

6.4.2 Cell Update 

Figure 27 illustrates an example of a cell update procedure. 

The cell update procedure is triggered by the cell re-selection function in the UE, which notifies which cell the UE 
should switch to. The UE reads the broadcast information of the new cell. Subsequently, the UE RRC layer sends a 
CELL UPDATE message to the UTRAN RRC via the CCCH logical channel and the RACH transport channel. The 
RACH transmission includes the current S-RNTI and the SRNC Identity. 

Upon reception of the CELL UPDATE, the UTRAN registers the change of cell. If the registration is successful it 
replies with a CELL UPDATE CONFIRM message transmitted on the DCCH/FACH to the UE. The message includes 
the current S-RNTI and SRNC Identities and it may also include new S-RNTI and / or S-RNTI + SRNC Identities. By 
using DCCH for the confirm message the contents of the message can be ciphered. 
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Figure 27: Cell update procedure 
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6.4.3 URA Update 

Figure 28 illustrates an example of a URA Update procedure. For a more detailed figure on the interlayer interaction for 
CCCH or DCCH transmission please refer to "Cell Update" in the previous subclause. 

When cell re-selection is triggered, the UE abandons the radio link in the old cell and establishes a radio link to the new 
cell. The URA update procedure is triggered when the UE reads the broadcast information of the new cell and 
recognises that a URA update is required. After that, the UE RRC layer sends a URA UPDATE on the CCCH to the UE 
MAC layer, which transfers the message on the RACH to UTRAN. The RACH transmission includes the current 
S-RNTI and SRNC Identity. 

Upon reception of the URA UPDATE, the UTRAN registers the change of URA. Then the CRNC-RRC requests the 
CRNC-MAC to send a URA UPDATE CONFIRM message on the EACH to the UE. The message includes the current 
S-RNTI and SRNC Identities and may also include new C-RNTI, S-RNTI and SRNC Identities. 

The logical channel used for URA UPDATE CONFIRM depends on the SRNC relocation policy. If SRNC is always 
relocated before URA UPDATE CONFIRM is sent, a DCCH should be used (to allow ciphering of the message 
contents). If SRNC is not relocated, the CCCH logical channel should be used to be able to utilize the RNS AP lur 
procedures and not being forced to set up user plane on the lur for this procedure. 
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Figure 28: Beginning of the URA update procedure - continue either to case A or case B 
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Figure 29: Case A continuation of URA update, CONFIRIVI message can be ciphered 

Case B: URA UPDATE CONFIRM on CCCH: 

In this case transmission between SRNC and CRNC takes place on the RNSAP Downhnk Signalling Transfer and the CCCH logical channel is used. 
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Figure 30: Case B continuation of URA update, CONFIRIVI message cannot be ciphered 
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6.4.4 Radio Link Addition (FDD soft-add) 

NOTE: TDD soft-add is an option supported on the condition that LI supports it. 
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Figure 31 : Radio Link Addition 

Figure 3 1 illustrates a radio link addition procedure. Radio link addition is triggered in the network RRC layer by 
measurement reports sent by the UE. The NW RRC first configures the new radio link on the physical layer in 
Node B. Transmission and reception begin immediately. The NW RRC then sends an RRC ACTIVE SET 
UPDATE message to the UE RRC. The UE RRC configures layer 1 to begin reception. 

After confirmation from the physical layer in UE an ACTIVE SET UPDATE COMPLETE message is sent to 
the RNC-RRC. 
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6.4.5 Radio Link Removal (FDD soft-drop) 

NOTE: TDD soft-drop is an option supported on the condition that LI supports it. 
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Figure 32: Radio link removal 

Figure 32 illustrates a radio link removal procedure. Radio link removal is triggered by an algorithm in the 
network RRC layer by measurement reports sent by the UE. Radio link removal may also be triggered in the NW 
due to load control algorithms. The radio link is first deactivated by the UE and then in the NW. 

The NW RRC sends an ACTIVE SET UPDATE message to the UE RRC. The UE RRC requests UE LI to 
terminate reception of the radio link(s) to be removed. After this the UE RRC acknowledges radio link removal 
with an ACTIVE SET UPDATE COMPLETE message to the NW RRC. The NW RRC proceeds to request the 
NW LI in both Node B and the RNC to release the radio hnk. 
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6.4.6 Combined radio linl< addition and removal 
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Figure 33: Combined Radio Link Addition And Removal 

Figure 33 illustrates a combined radio link addition and removal procedure. The NW RRC determines the need 
for radio link replacement based on received measurement reports or load control algorithms. 

When radio links are to be replaced, the NW RRC first configures the NW LI to activate the radio link(s) that 
are being added. The NW RRC then sends an ACTIVE SET UPDATE message to the UE RRC, which 
configures the UE LI to terminate reception on the removed radio link(s) and begin reception on the added radio 
Unk(s). 

If the UE active set is full, the replacement has to be performed in the order defined in figure 33. If UE has only 
one radio link, then the replacement must be done in reverse order (first add, then remove). 

The UE RRC acknowledges the replacement with an ACTIVE SET UPDATE COMPLETE message. The NW 
RRC then configures the NW LI to terminate reception and transmission on the removed radio link. 
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6.4.7 Hard Handover (FDD and TDD hard) 
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Figure 34: l-lard handover 

Figure 34 illustrates a hard handover. The NW RRC determines the need for hard handover based on received 
measurement reports or load control algorithms. 

For inter-frequency handover the measurements are assumed to be performed in slotted mode. 

The NW RRC first configures the NW LI to activate the new radio links. The NW LI begins transmission and 
reception on the new links immediately. The NW RRC then sends the UE RRC a HANDOVER COMMAND 
message. The message indicates the radio resources that should be used for the new radio link. The UE RRC 
configures the UE LI to terminate reception on the old radio link and begin reception on the new radio link. 

After the UE LI has achieved downlink synchronisation on the new frequency, a L2 link is established and the 
UE RRC sends a HANDOVER COMPLETE message to the NW RRC. After having received the L3 
acknowledgement, the NW RRC configures the NW LI to terminate reception and transmission on the old radio 
hnk. 
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6.4.8 SRNS Relocation 

The SRNS relocation procedure can be divided into two phases. The first phase is relocation preparation; where 
the resources are reserved, new RABs are established while the second phase is the transfer of the Serving RNS 
from source to target RNC. 

There are three cases in which an SRNS relocation can be performed: 

Serving SRNS relocation: This is used to move the UTRAN to CN connection point at the UTRAN side 
from the source SRNC to the target RNC. 

Combinded Hard Handover and SRNS relocation: This is used to move the UTRAN to CN connection 
point at the UTRAN side from the source SRNC to the target RNC, while performing a hard handover 
decided by the UTRAN. 

Combined Cell/URA update and SRNS relocation: This is used to move the UTRAN to CN connection 
point at the UTRAN side from the source SRNC to the target RNC, while performing a cell re-selection 
in the UTRAN. 

and these are described in subclause 6.4.8.1 and 6.4.8.2, and in more detail in TS 23.060 [6]. 

6.4.8.1 Serving and Combined Cell/URA Update SRNS relocation 

The procedure is initiated by the source RNC deciding to perform a Serving SRNS relocation. Case I represents 
the situation when the UE is not involved and this is shown in Figure 35. Case II represents the situation when 
the UE is involved and a Combined Cell/URA update and SRNS relocation is performed, also shown in Figure 
35. 

A RANAP Relocation Command is received by the source RNC from the CN, indicating the RABs to be 
released and the RABs that are subject to data forwarding. Lossless SRNS relocation is always, and only, 
configured for RABs that are subject to data forwarding. The PDCP layer shall support PDCP sequence 
numbering when lossless SRNS relocation is supported [7]. 

For the affected radio bearers, the RLC entity is suspended and the PDCP sequence numbers are retrieved by 
RRC. The PDCP send and receive sequence numbers are then transferred in the RNSAP Relocation Commit 
message from source to target RNC for RABs that support lossless SRNS relocation. The target RNC becomes 
the serving RNC when the RANAP Relocation Detect message is sent. 

The target RNC then sends a UTRAN MOBILITY INFORMATION (Case I) or a CELL/URA UPDATE 
CONFIRM (Case II); which configures the UE with the new U-RNTI and indicates the uplink receive PDCP 
sequence number for each radio bearer configured to support lossless SRNS relocation. The UE compares the 
uplink receive PDCP sequence number with the UE uplink send PDCP sequence number. If this confirms PDCP 
SDUs successfully transferred before the start of relocation ie already received by the source RNC then these are 
discarded by the UE. 

If the UE has successfully configured itself, it shall send; a UTRAN MOBILITY INFORMATION CONFIRM 
(Case I and Case II). These messages contain the downlink receive PDCP sequence number for each radio bearer 
configured to support lossless SRNS relocation. UTRAN compares the downlink receive PDCP sequence 
number with the downlink send PDCP sequence number For the affected radio bearers. The RLC entity is re- 
established [2] with the current configuration. 

In case of failure; the UE shall send a UTRAN MOBILITY INFORMATION FAILURE (Case I) or CELL/URA 
UPDATE FAILURE (Case II) message. 

Upon reception of the UTRAN MOBILITY INFORMATION CONFIRM/FAILURE (Case I and Case II) or 
CELL/URA UPDATE COMPLETE/FAILURE (Case II) message, UTRAN shall start the PDCP entity and the 
relocation procedure ends. 
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Figure 35: Serving and Combined Cell/URA Update SRNS relocation 
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6.4.8.2 Combined Hard Handover and SRNS relocation 

Based on measurement results and knowledge of the UTRAN topology, the source SRNC decides to initiate a 
combined hard handover and SRNS relocation. The UE is still under control of the SRNC but is moving to a 
location controlled by the target RNC. 

A RANAP Relocation Command is received by the source RNC from the CN, indicating the RABs to be 
released, the Target RNC to Source RNC Transparent Container and the RABs that are subject to data 
forwarding. Lossless SRNS relocation is always, and only, configured for RABs that are subject to data 
forwarding. The PDCP layer shall support PDCP sequence numbering when lossless SRNS relocation is 
supported [7]. 

The Target SNC to Source RNC Transparent Container includes the RRC message (XXX) for hard handover. 
Upon reception of the RANAP Relocation Command, the source RNC triggers the execution of the relocation of 
SRNS by sending message XXX to the UE. This message includes the new U-RNTI and the uplink receive 
PDCP sequence number for each radio bearer configured to support lossless SRNS relocation. The UE compares 
the uplink receive PDCP sequence number with the uplink send PDCP sequence number. If this confirms PDCP 
SDUs successfully transferred before the start of relocation ie already received by the source RNC then these are 
discarded by the UE. 

For the affected radio bearers, the RLC entity is suspended and the PDCP sequence numbers are retrieved by 
RRC. The PDCP send and receive sequence numbers are then transferred during the forwarding of SRNS 
contexts via the CN phase from source to target RNC for RABs that support lossless SRNS relocation. The target 
RNC becomes the serving RNC when the RANAP Relocation Detect message is sent. 

If the UE has successfully configured itself, it shall send a XXX COMPLETE message to the target RNC. This 
message contains the downlink receive PDCP sequence number for each radio bearer configured to support 
lossless SRNS relocation. UTRAN compares the downlink receive PDCP sequence number with the downlink 
send PDCP sequence number. For the affected radio bearers, the RLC entity is re-established [2] with the current 
configuration. 

In case of failure, the UE shall send a XXX FAILURE message to the target RNC. 

Upon reception of the XXX COMPLETE/FAILURE, UTRAN shall start the PDCP entity and the relocation 
procedure ends. 
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Figure 36: Combined Hard Handover and SRNS relocation 
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Figure 37: RRC connection re-establishment 



£75/ 



3GPP TS 25.303 version 3.5.0 Release 1 999 65 ETSI TS 1 25 303 V3.5.0 (2000-09) 

Figure 37 shows an example of an RRC connection re-establishment procedure. RRC connection re-establishment is 
needed, when a UE loses radio connection due to e.g. radio link failure. After having selected a new cell, the UE RRC 
sends the NW RRC an RRC CONNECTION RE-ESTABLISHMENT REQUEST message. The NW RRC configures 
the NW and acknowledges the connection re-establishment to the UE RRC with an RRC CONNECTION RE- 
ESTABLISHMENT message. The UE RRC configures the UE LI to activate the new radio link(s). After the UE has 
synchronised to at least one radio link, the MAC and RLC layers can be configured (if necessary). 

When the procedure is completed on the UE side, an RRC CONNECTION RE-ESTABLISHMENT COMPLETE 
message is sent. 

6.4. 1 Inter-system Handover: GSM/BSS to UTRAN 

The handover from GSM/BSS to UTRAN for a dual-mode GSM MS / UMTS UE is illustrated in figure 38. On the 
network side, upon the reception of a HARD HANDOVER PROCEED 2 command through the RANAP protocol, the 
RRC layer performs admission control and radio resource allocation assigning an RNTI for the RRC connection and 
selecting radio resource parameters (such as transport channel type, transport format sets, etc). RRC configures these 
parameters on layer 1 and layer 2 to locally establish the DCH logical channel. 

The selected parameters including the RNTI, were previously transmitted to UE via RANAP message HARD 
HANDOVER PROCEED 1 and GSM upgraded message HANDOVER COMMAND. 

Upon reception of the HANDOVER COMMAND message, the GSM RR layer transmits the required parameters to the 
UMTS RRC layer using an RR-Data-IND primitive. UE RRC configures LI and L2 using these parameters to locally 
establish the DCH logical channel. Layer 1 indicates to RRC when it has reached synchronisation. An RLC signalling 
Unk estabhshment is then initiated by the UE. A HANDOVER COMPLETE message is finally sent by the UE. 
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Figure 38: GSIVI to UIVITS inter-system handover 
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Figure 39: UIUITS to GSIVI inter-system handover 
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NOTE: The scope of this description is restricted to a UE having a connection only to PSTN/ISDN services, 
i.e. no simuhaneous IP connection. 

For PSTN/ISDN domain services UTRAN Inter-System Handover procedure is based on measurement reports from the 
UE but initiated from the UTRAN. INTER-SYSTEM HANDOVER COMMAND is sent using acknowledged data 
transfer on the DCCH. The UE transition from UTRAN Connected Mode starts when an INTER-SYSTEM 
HANDOVER COMMAND is received. The transition to GSM Connected mode is finished when HANDOVER 
COMPLETE message is sent from the UE. 

UTRAN sends a HANDOVER REQUIRED to CN/AS. This message contains information needed for the GSM system 
to be able to perform a handover (e.g. serving cell, target cell). Some parts of this information (e.g. MS classmark) have 
been obtained at call setup of the UTRAN Connection and are stored in CN. 

The CN/AS sends a HANDOVER REQUEST message to BSC-RR allocating the necessary resources to be able to 
receive the GSM MS and acknowledge this by sending HANDOVER REQUEST ACKNOWLEDGE to CN/AS. The 
HANDOVER REQUEST ACKNOWLEDGE contains all radio-related information that the UE needs for the handover. 

CN/AS sends a INTER-SYSTEM HANDOVER COMMAND (type UTRAN-to-BSS HARD HANDOVER) to the UE 
to start the execution of the handover. This message contains all the information needed for the UE to be able to switch 
to the GSM cell and perform a GSM handover. 

Upon reception of the HANDOVER COMMAND message, UMTS RRC forwards the handover mparameters to the 
GSM RR layer using an RRC-Data-IND primitive. To release the resources from UMTS the RR layer transmits to the 
UMTS RRC an RRC Connection Release message using an RR-Data-IND primitive. The RRC layer can then locally 
release the resources on the RLC, MAC and physical layers of the UE. 

After having switched to the assigned GSM channel received in the INTER-SYSTEM HANDOVER COMMAND, the 
GSM MS sends HANDOVER ACCESS in successive layer 1 frames, just as it typically would have done for a 
conventional GSM handover initiation. 

When the BSC-RR has received the HANDOVER ACCESS it indicates this to the CN/AS by sending a HANDOVER 
DETECT message. The BSC-RR sends a PHYSICAL INFORMATION message to the GSM MS in unacknowledged 
mode that contains various fields of physical layer -related information allowing a proper transmission by the MS. 

After layer 1 and 2 connections are successfully established, the GSM MS returns the HANDOVER COMPLETE 
message. 

CN/AS is then able to release the UTRAN resources that were used for the UE in UTRAN Connected Mode. The 
CN/AS send a BEARER RELEASE command to UTRAN, after which UTRAN can release all NW resources from 
RLC, MAC and the physical layer. When the release operation is complete, a BEARER RELEASE COMPLETE 
message is sent to CN / AS. 



£75/ 



3GPP TS 25.303 version 3.5.0 Release 1999 



69 



ETSI TS 125 303 V3.5.0 (2000-09) 



6.5 CN originated paging request in connected mode 
6.5.1 UTRAN coordinated paging using DCCH 
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Figure 40: Example sequence of CN initiated paging request using DCCH 
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The above sequence illustrates a CN originated paging request, when the UE is in connected mode and can be reached 
on the DCCH. The coordination of the paging request with the existing RRC connection is done in UTRAN. 

The entity above RRC on the network side requests paging of a UE over the Nt-SAP. The request contains a UE paging 
identity, an area where the page request is to be broadcast, information for calculation of the paging group and NAS 
information to be transparently transmitted to the UE by the paging request. 

Since the UE can be reached on the DCCH, the RRC layer formats a Paging Request Type 1 message containing the UE 
paging identity and the NAS information, and the message is transmitted directly to the UE using unacknowledged data 
transfer. 
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6.6 UTRAN originated paging request and paging response 
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Figure 41 : Example sequence for UTRAN initiated paging request with paging response 
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The RRC layer in the network uses this sequence to trigger a switch to RACH/FACH substate of the cell connected 
state, when the UE can only be reached on the PCH (the PCH substate of cell connected state or the URA connected 
state). A Paging Type 1 message is prepared, containing the UTRAN UE identity (s-RNTI + RNC-ID). The RRC 
requests the transmission of the message by MAC on the PCCH, indicating the paging group. 

In the UE, the RRC layer continuously monitors the paging group on the PCH and compares the UE identities in 
received paging request messages with its own identities. A match occurs, and in this case the RRC layer changes state 
to RACH/FACH substate within the cell connected mode. 

The UE prepares a Cell Update message, which is sent on CCCH. 

When the network receives the Cell Update message, a c-RNTI is allocated and signalled to UE using the Cell Update 
Confirm message, which is sent on DCCH using unacknowledged mode. The latter message also acknowledges the 
reception of the Cell Update message. The UE configures MAC to use the new c-RNTI and prepares a UTRAN 
MOBILITY INFORMATION CONFIRM message. When the network receives the UTRAN MOBILITY 
INFORMATION CONFIRM message on DCCH it can delete any old c-RNTI and the DCCH/DTCH logical channels 
can be used also in the downlink using the new c-RNTI. 

6.7 Other procedures 
6.7.1 UE Capability Information 
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Figure 42: UE Capability Information 

The UE transfers its capability information to the network by transmitting the RRC message UE Capability Information 
using acknowledged mode on the DCCH. This procedure can (optionally) be performed after RRC Connection Setup 
procedure and also during the lifetime of the RRC Connection if the UE capability information changes (e.g. due to 
change in UE power class). UE capability information can also explicitly be requested by UTRAN. 
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6.7.2 Random access transmission sequence (FDD) 
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Figure 43: Random access transmission sequence (FDD) 

The RACH and AICH are configured once via a CPHY-TrCH-Config-REQ primitive. This primitive is issued only for 
initial configuration or when a parameter shall be changed, not for every RACH transmission. 

The CMAC-Config-REQ primitive is used to configure MAC parameters required for the random access procedure 
(e.g. persistence value, maximum number of preamble ramping cycles, initial and subsequent backoff times). 

When there is data to be transmitted on the RACH, i.e. reception of a MAC-Data-REQ primitive, the RACH 
transmission control procedure is started, which includes selection of Access Service Class (ASC). 

After some initial backoff, a primitive PHY-Access-REQ containing the selected ASC is sent to LI. This triggers the 
PRACH preamble transmission procedure, i.e. the physical layer selects a PRACH access slot and signature without 
further backoff delay imposed on LI, but within the constraints of the selected ASC. 

If the maximum permitted transmission power was reached without receiving an acknowledgement, or a negative 
acknowledgement (Nack) has been received on AICH, the preamble ramping cycle is repeated. The number of preamble 
ramping cycles is counted in MAC. 

Upon successful transmission of a preamble, MAC receives an acknowledgement via PHY-Access-CNF primitive that 
the acquisition indicator was received. Then message transmission is requested with the PHY-Data-REQ primitive. 
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6.7.3 Random access transmission sequence (TDD) 
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Figure 44: Random access transmission sequence (TDD) 

The RACH is configured once via a CPHY-TrCH-Config-REQ primitive. This primitive needs to be used only for 
initial configuration (e.g. power parameter) or when a parameter shall be changed, not for every RACH transmission. 

The CMAC-Config-REQ primitive is used to configure MAC parameters required for the random access procedure. 
The parameters could include random access control parameters such as, persistence value and Access Service Class 
(ASC) parameters. 

When there is data to be transmitted on the RACH, i.e. reception of a MAC-Data-REQ primitive, the RACH 
transmission control procedure is started, which includes selection of an Access Service Class (ASC). 

After some backoff, a primitive PHY-Data-REQ is sent to LI, which triggers the PRACH message transmission, i.e. the 
physical layer selects a PRACH spreading-code without further backoff delay imposed on LI, but within the constraints 
of the selected ASC. Note that the backoff time on MAC may in certain conditions be set to zero (e.g. when the uplink 
load is low). 

At the UTRAN-side MAC the further processing of received RACH message depends on the MAC header. An 
acknowledgement that the message was received correctly is given by a RRC procedure. In case of transparent RLC, 
message retransmission shall be handled entirely on RRC employing retransmission timers. In case of non-transparent 
RLC, the timers are controlled by the RLC. The parameters of PRACH transmission are chosen such that the number of 
retransmissions for the messages are kept low. Message loss on the PRACH should be due to a collision on the same 
spreading code. 
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6.7.4 CPCH Emergency Stop sequence 



Figure 45 illustrates the CPCH emergency stop procedure. This procedure is invoked by a request from Node B RRC, 
when Node B detects emergency stop conditions such as temporary overload situation in the cell. CPCH emergency 
stop is initiated by CPHY-CPCH-Estop-REQ primitive issued from Node B RRC to Node B LI. Upon the reception of 
this primitive, Node B LI sends CPCH emergency stop command to UE LL 

Upon the reception of emergency stop command, UE LI sends CPHY-CPCH-Estop-IND primitive to UE RRC 
indicating the reception of CPCH emergency stop command. Then, UE RRC replies with CPHY-CPCH-Estop-Resp 
primitive to command UE LI to execute CPCH emergency stop. After UE LI stops on-going CPCH transmission, it 
sends PHY-Status-IND primitive to UE MAC indicating the completion of CPCH Emergency stop. Meanwhile, when 
Node B LI detects CPCH Unk loss, it sends CPHY-CPCH-Estop-CNF primitive to Node B RRC. This completes CPCH 
emergency stop procedure. 
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Figure 45: CPCH Emergency Stop Sequence 



Traffic volume monitoring 



An algorithm will be defined for the UE to trigger a message to the NW based on transmitter buffer status. 

Figure 46 illustrates the example of message sequence of traffic volume monitoring procedure. RRC in UE gets the 
parameters necessary for traffic volume measurement from Measurement Control message or System information 
message sent by RRC in UTRAN. RRC in UE passes the MAC the parameters for traffic volume measurement with the 
CMAC-Measurement-REQ. Meanwhile, RLC passes the data to MAC with buffer status. There are two ways MAC 
indicates the traffic volume measurement report to RRC, periodic and event-triggered. If it is periodic report, the MAC 
reports the measurement result to RRC periodically. If it is event-triggered, MAC in UE reports the measurement result 
to RRC when the result is beyond the specified threshold value. After that, based on the measurement report from MAC 
and reporting criteria received from UTRAN, RRC makes a decision whether it should send Measurement Report 
Message to UTRAN. When RRC in UTRAN receives the Measurement Report Message, it takes a proper action based 
on the measurement report from UE. It can be bearer reconfiguration, transport channel reconfiguration, physical 
channel reconfiguration or transport channel combination control procedure. The report mode, periodic and event- 
triggered, can be used exclusively, or simultaneously as shown in figure 1 . 
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Figure 46: Traffic Volume IVIeasurement Report Procedure 
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Annex A (informative): 

RRC Connection Establishment - Case C 

This protocol termination case has been excluded from the initial UMTS release, thus the procedure is captured here for 
information. 
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Figure A.1 : RRC connection establishment with common channel termination case C 
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The difference between case A and case C common channel termination points is that in case C RACH and FACH 
transport channels are terminated in Node B. An Access Acknowledgement message is sent from Node B to the UE to 
acknowledge the reception of the Access request. Similarily, the Access Grant message from the network is transmitted 
via the Node-B MAC. 
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